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6.2.1 Composition of IMEI 

The International Mobile station Equipment Identity (IMEI) is composed as shown in figure 10. 

6 d ig its 2 d ig its 6 d ig its I d ig it 

'^^^ FAC SNR spare 

IM E I 1 5 d ig its 

Figure 10: Structure of IMEI 

The IMEI is composed of the following elements (each element shall consist of decimal digits only): 
Type Approval Code (TAG). Its length is 6 digits; 

Final Assembly Code (FAC) identifies the place of manufacture/final assembly. Its length is 2 digits; 

Serial Number (SNR) is an individual serial number uniquely identifying each equipment within each TAG 
and FAC. Its length is 6 digits; 

Spare digit: this digit shall be zero, when transmitted by the MS. 
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The IMEI (14 digits) is complemented by a check digit. The check digit is not part of the digits transmitted at IMEI 
check occasions, as described below. The Check Digit shall avoid manual transmission errors, e.g. when customers 
register stolen MEs at the operators customer care desk. The Check Digit is defined according to the Luhn formula, 
as defined in annex B. 

NOTE: The Check Digit is not applied to the Software Version Number. 
The security requirements of the IMEI are defined in 3G TS 22.016. 



Page 5 



NEXT MODIFICATION ***♦♦♦*♦♦♦•♦♦*••*♦*♦♦♦♦♦♦♦♦♦♦** 



A _ A.'. \ . 

http://66. 102. 11.1 04/search?q=cache:7Pi 101jIvuQJ:www.3gpp.org/ftp/tsg_cnyTSG_CN/TSGN... 1/6/04 



CHANGE REQUEST 23.003 CR 022 

Annex a i^normaiivej: 

IMEI Check Digit computation 



Page 7 of 9 



B.l Representation of IMEI 

The International Mobile station Equipment Identity and Software Version Number (IMEIS V), as defined in TS 
23.003, is a 16 digit decimal number composed of four distinct elements: 

- a 6 digit Type Approval Code (TAC); 

- a 2 digit Final Assembly Code (FAC); 

- a 6 digit Serial Number (SNR); and 

- a 2 digit Software Version Number (S VN). 

The IMEI SV is formed by concatenating these four elements as illustrated below: 

TAC FAC SNR SVN 

Figure A.l : Composition of the IMEISV 

The IMEI is complemented by a check digit as defined in section 3. The Luhn Check Digit (CD) is computed on the 
14 most significant digits of the IMEISV, that is on the value obtained by ignoring the SVN digits. 

The method for computing the Luhn check is defined in Annex B of the International Standard "Identification cards - 
Numbering system and registration procedure for issuer identifiers" (ISO/IEC 7812) [3]. 

In order to specify precisely how the CD is computed for the IMEI, it is necessary to label the individual digits of the 
IMEISV, excluding the SVN. This is done as follows: 

The (14 most significant) digits of the IMEISV are labelled DI4D13...D1, where: 

- TAC = D14 D13 ... D9 (with D9 the least significant digit of TAC); 

- FAC = D8 D7 (with D7 the least significant digit of FAC); and 

- SNR = D6 D5 ... Dl (with Dl the least significant digit of SNR). 



B.2 Computation of CD for an IMEI 

Computation of CD from the IMEI proceeds as follows: 

Step 1: Double the values of the odd labelled digits Dl, D3, D5 ... D 13 of the IMEI. 

Step 2; Add together the individual digits of all the seven numbers obtained in Step I , and then add this sum to 
the sum of all the even labelled digits D2, D4. D6 ... D14 of the IMEI. 
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Step 3: If the number obtained in Step 2 ends in 0, then set CD to be 0. If the number obtained in Step 2 does 

not end in 0, then set CD to be that number subtracted from the next higher number which does end in 
0. 



B.3 Example of computation 

IMEI (14 most significant digits): 



TAC FAC SNR 

D14D13D12 Dll D10D9 D8 D7 D6D5D4D3D2D1 

26053 1 79 3 11383 



Step 1: 

2605 3 1 79 3 1 1 3 83 

x2 x2 x2 x2 x2 x2 x2 

12 102 18 266 

Step 2: 

2+1 + 2 + 0+1+0 + 3 + 2 + 7+1 + 8 + 3 + 2+1+6 + 8 + 6 = 53 
Step 3: 

CD = 60 - 53 = 7 
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6.2.1 Composition of IMEI 

The International Mobile station Equipment Identity (IMEI) is composed as siiown in figure 10. 



6 digits 2 digits 6 digits 1 digit 

< > < > < > < > 



TAC 




FAC 




SNR 




spare 



IME1 15 digits 

K ^ 



Figure 10: Structure of IMEI 

The IMEI is composed of the following elements (each element shall consist of decimal digits only): 

- Type Approval Code (TAC). Its length is 6 digits; 

- Final Assembly Code (FAC) identifies the place of manufacture/final assembly. Its length is 2 digits; 

- Serial Number (SNR) is an individual serial number uniquely identifying each equipment within each TAC 
and FAC. Its length is 6 digits; 

Spare digit: this digit shall be zero, when transmitted by the MS. 

The IMEI (14 digits) is complemented by a check digit. The check digit is not part of the digits transmitted at IMEI 
check occasions, as described below. The Check Digit shall avoid manual transmission errors, e.g. when customers 
register stolen MEs at the operators customer care desk. The Check Digit is defined according to the Luhn formula, 
as defined in annex B. 

NOTE: The Check Digit is not applied to the Software Version Number. 



The security requirements of the IMEI are defined in 3G TS 22.016. 
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Annex B (normative): 

IMEI Check Digit computation 

B.1 Representation of IIVIEI 

The International Mobile station Equipment Identity and Software Version Number (IMEISV). as defined in TS 
23.003, is a 16 digit decimal number composed of four distinct elements: 

- a 6 digit Type Approval Code (TAP: 

- a 2 digit Final Assembly Code (FACV 

- a 6 digit Serial Number (SNR): and 

- a 2 digit Software Version Number (SVN). 

The IMEISV is formed by concatenating these four elements as illustrated below: 

I TAC I FAC I SNR | SVN | 



Figure A.1: Composition of the IIVIEISV 

The IMEI is complemented by a check digit as defined in section 3. The Luhn Check Digit (CD) is computed on the 
14 most significant digits of the IMEISV. that is on the value obtained by ignoring the SVN digits. 

The method for computing the Luhn check is defined in Annex B of the International Standard "Identification cards - 
Numbering system and registration procedure for issuer identifiers" (ISO/IEC 7812) [3]. 

In order to specify precisely how the CD is computed for the IMEI. it is necessary to label the individual digits of the 
IMEISV. excluding the SVN. This is done as follows: 

The (14 most significant) digits of the IMEISV are labelled D14 D13 ... Dl. where: 

- TAC = D14D13... D9 (with D9 the least significant digit of TAC): 

- FAC = D8 D7 (with D7 the least significant digit of FAC): and 

- SNR = D6D5 ...Dl (with Dl the least significant digit of SNR). 



B.2 Computation of CD for an IMEI 

Computation of CD fi-om the IMEI proceeds as follows: 

Step 1: Double the values of the odd labelled digits Dl. D3. D5 ... D13 of the IMEI. 



Step 2: Add together the individual digits of all the seven numbers obtained in Step 1 . and then add this sum to 

the sum of all the even labelled digits D2. D4. D6 ... D14 of the IMEI. 



Step 3: 



If the number obtained in Step 2 ends in 0. then set CD to be 0. If the number obtained in Step 2 does 
not end in 0, then set CD to be that number subtracted from the next higher number which does end in 



0. 



B.3 Example of computation 



IMEI (14 most significant digits): 



TAC 


FAC 


SNR 


D14 D13 


D12 


Dll 


DIO 


D9 


D8 


D7 


D6 


D5 


D4 D3 


D2 


Dl 


2 6 


0 


5 


3 


1 


7 


9 


3 


1 


1 3 


8 


3 


Step 1: 
























2 6 


0 


5 


3 


1 


7 


9 


3 


1 


1 3 


8 


3 


x2 




x2 




x2 




x2 




x2 


x2 




x2 


12 




10 




2 




18 




2 


6 




6 


Step 2: 
























2+1+2+0+1+0+3+2+7+1+8+3+2+1+6+ 


8 + 6- 


53 









Step 3: 

CD = 60 - 53 ^ 7 
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Source: Nokia 

Title: Proposal to modify IMEI format 



Background 

The current IMEI format is structured in the following way: 

o Type Approval Code (TAC): 6 digits. The first 2 digits constitute the code allocated 
to Notified Body = Reporting Body ldentifier( 1900 MHz phones in USA and test 
terminals have different coding) 

o Final Assembly Code (FAC): 2 digits 

o Serial Number: 6 digits 

o Check digit 

These digits have been presented in BCD format. New Type Approval Codes have been 
issued with a 6 BCD digits Serial Number set (1 Million units) is not sufficient any more. This 
format has served well and no problems have been envisaged as far as an unambiguous 
terminal coding for GSM is concerned. However, the introduction of the IMEI into 3G mobile 
terminal identification changes the situation as soon as a great variety of products 
manufactured in larger volumes will flow to market place. Nevertheless, any modification in the 
IMEI coding must not jeopardize smooth migration from one mobile generation to the next one. 



Proposal 

Given the strong reliance on the interoperability with legacy products no change to IMEI length 
or structure is considered feasible. In contrast, the coding format of the Serial Number is 
proposed to be modified. 

• Instead using BCD, a hexadecimal code format is proposed. It would offer a capacity of 
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16.7 Million units manufactured with one Type Approval Code. 
• TAG would set a trigger for interpretation ( Network would identify from which TAG 
number onwards a serial number would be interpreted as binary presentation) 



This proposal will require modifications to network management system for both installed and 
new (GSM and 3G). But no modifications to existing Rel *99 signalling is foreseen. 

Ghange of coding is proposed for release 2000. However, change should be considered 
already for release 1999 in order to allow new IME coding in all 3G terminals. 

Attached GR to 22.016 for Release 2000. 
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Annex A (normative): 

IMEI Check Digit computation 

A.1 Representation of IMEI 

The International Mobile station Equipment Identity and Software Version Number (IMEISV), as defined in TS 23.003, is a 
16 digit hexadecimal number composed of four distinct elements! 

- a 6 digit Type Approval Code (TAC); 

- a 2 digit Final Assembly Code (FAC); 

- a 6 digit Serial Number (SNR); and 

- a 2 digit Software Version Number (SVN). 

The IMEISV is formed by concatenating these four elements as illustrated below: 

I TAC 



FAC 



SNR 



SVN I 



Figure A.1: Composition of the IMEISV 

The IMEI is complemented by a check digit as defined in section 3. The modulus 16 Luhn Check Digit (CD) is computed 
on the 14 most significant hexadecimal digits of the IMEISV, that is on the value obtained by ignoring the SVN digits. 

The method for computing the Luhn check is defined in Annex B of the International Standard "Identification cards - 
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Numbering system and registration procedure for issuer identifiers" (ISO/IEC 7812) [3]. The modulus 16 Luhn Check Digit 
is identical, but number base has been transformed from 10 to 16. 

In order to specify precisely how the CD is computed for the IMEI, it is necessary to label the individual digits of the 
IMEISV, excluding the SVN. This is done as follows: 

The (14 most significant) digits of the IMEISV are labelled D14 D13 ... Dl, where: 

- TAC = D14 D13 ... D9 (with D9 the least significant digit of TAC); 

- FAC = D8 D7 (with D7 the least significant digit of FAC); and 

- SNR = D6 D5 ... Dl (with Dl the least significant digit of SNR). 

Note: Even though all digits Dl □ D14 are changed to use hexadecimal coding, this has no effect to the previously assigned 
values of all fields when the fields were using BCD coding. The same code values can still be used for the previously 
assigned codes. The hexadecimal coding allows more codes to be used for all fields. Especially this applies to the SNR field, 
which has number space of 2^24 = 16,777,216 units □ with BCD coding the number space is 1,000,000 units. 



Step 1: Double the values of the odd labelled digits HI, H3, H5, ... H13 of the IMEI using hexadecimal 
number base. 

Step 2: Add together the individual digits of all the seven numbers obtained in Step 1 , and then add this sum to 
the sum of all the even labelled digits H2, H4, H6, ... H14 of the IMEI using hexadecimal number base. 

Step 3: If the number obtained in Step 2 ends in 0, then set CD to be 0. If the number obtained in Step 2 does 
not end in 0, then set CD to be that number subtracted from the next higher hexadecimal number which does 
end in 0. 



A.2 Computation of CD for an IMEI 



Computation of CD from the IMEI proceeds as follows: 



A.3 Example of computation 



IMEI (14 most significant digits): 



TAC 

H14 H13 H12 H11 H10 H9 
26053 1 



FAC 
H8 H7 
79 



SNR 

H6 H5 H4 H3 H2 H1 
38D3E3 



Step 1: 



26053 1 
x2 x2 x2 
C A 2 



79 



x2 
12 



38D3E3 
x2 x2 x2 
10 6 6 
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Step 2: 

2+C+0+A+3+2+7+l+2+3+l+0+D+6+E+6=52 

Step 3: 

CD = 60 - 52 = E 
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Source: Nokia 

Title: Proposal to modify IMEI format 



Background 

The current IMEI format is structured in the following way: 

■ Type Approval Code (TAG): 6 digits. The first 2 digits constitute the code allocated to 
Notified Body = Reporting Body ldentifier( 1900 MHz phones in USA and test terminals 
have different coding) 

■ Final Assembly Code (FAC): 2 digits 

■ Serial Number: 6 digits 

■ Check digit 

These digits have been presented in BCD format. New Type Approval Codes have been issued with a 6 
BCD digits Serial Number set (1 Million units) is not sufficient any more. This format has served well and 
no problems have been envisaged as far as an unambiguous terminal coding for GSM is concerned. 
However, the introduction of the IMEI into 3G mobile terminal identification changes the situation as soon 
as a great variety of products manufactured in larger volumes will flow to market place. Nevertheless, 
any modification in the IMEI coding must not jeopardize smooth migration from one mobile generation to 
the next one. 

Proposal 

Given the strong reliance on the interoperability with legacy products no change to IMEI length or 
structure is considered feasible. In contrast, the coding format of the Serial Number is proposed to be 
modified. 

■ Instead using BCD, a hexadecimal code format is proposed. It would offer a capacity of 16.7 Million 
units manufactured with one Type Approval Code. 

■ TAC would set a trigger for interpretation { Network would identify from which TAC number onwards 
a serial number would be interpreted as binary presentation) 

This proposal will require modifications to network management system for both installed and new (GSM 
and 3G). But no modifications to existing Rel '99 signalling is foreseen. 

Change of coding is proposed for release 2000, However, change should be considered already for 
release 1999 in order to allow new IME coding in all 3G tenninals. 

Attached CR to 22.016 for Release 2000. 
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Annex A (normative): 

IMEI Check Digit computation 



A. 1 Representation of I M E I 



The International Mobile station Equipment Identity and Software Version Number (IMEISV), as defined in TS 23,003, is a 16 
digit hexa decimal number composed of four distinct elements: 

- a 6 digit Type Approval Code (TAG); 

- a 2 digit Final Assembly Code (FAC); 

- a 6 digit Serial Number (SNR); and 

- a 2 digit Software Version Number (SVN). 

The IMEISV is formed by concatenating these four elements as illustrated below: 

SVN~| 



TAG 



FAC SNR 



Figure A.1: Composition of the IMEISV 



The IMEI is complemented by a check digit as defined in section 3. The modulus 16 Luhn Check Digit (CD) is computed on 
the 14 most significant hexadecimal digits of the IMEISV, that is on the value obtained by ignoring the SVN digits. 
The method for computing the Luhn check_ is defined in Annex B of the International Standard "Identification cards - 
Numbering system and registration procedure for issuer identifiers" (ISO/IEC 7812) [31. The modulus 16 Luhn Check Digit is 
identical, but number base has been transformed from 10 to 16. 

In order to specify precisely how the CD is computed for the IMEI, it is necessary to label the individual digits of the IMEISV, 
excluding the SVN. This is done as follows: 

The (14 most significant) digits of the IMEISV are labelled D14 D13 ... Dl, where: 

- TAC = D14 D13 ... D9 (with D9 the least significant digit of TAC); 

- FAC = D8 D7 (with D7 the least significant digit of FAC); and 

- SNR = D6 D5 ... Dl (with Dl the least significant digit of SNR). 

Note: Even though all digits Dl . .. D14 are changed to use hexadecimal coding, this has no effect to the previously assigned 
values of all fields when the fields were using BCD coding. The same code values can still be used for the previously assigned 
codes. The hexadecimal coding allows more codes to be used for all fields. Especially this applies to the SNR field, which has 
number space of 2^24 = 16.777.216 units - with BCD coding the number space is 1.000.000 units. 



A.2 Computation of CD for an IMEI 

Computation of CD from the IMEI proceeds as follows: 

Step 1: Double the values of the odd labelled digits HDl, HD3, H©5, ... HD13 of the IMEI using hexadecimal number 
base . 

Step 2: Add together the individual digits of all the seven numbers obtained in Step 1, and then add this sum to the sum 
of all the even labelled digits HD2, HD4, HD6, ... HD14 of the IMEI using hexadecimal number base . 

Step 3: If the number obtained in Step 2 ends in 0, then set CD to be 0. If the number obtained in Step 2 does not end in 
0, then set CD to be that number subtracted from the next higher hexadecimal number which does end in 0. 
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A.3 Example of computation 



IMEI (14 most significant digits): 



TAG 


FAC 


SNR 


HB14HB13HD12HO11HB10 HD9 


HB8 HD7 


HB6 HD5 HB4 HB3 HD2 H01 


2 6 0 5 3 


1 


7 9 


3 84 D4 3 E8 3 


Step1: 








2 6 0 5 3 


1 


7 9 


3 84 D4 3 E8 3 


x2 x2 


x2 


x2 


x2 x2 x2 


C43 A40 


2 


128 


102 6 6 


Step 2: 





2 + C+4^ + 0 + A+4-Q + 3 + 2 + 7+l +2« + 3 +JL+03 + D4- + 6 + E« + 6 = 52#a 



Step 3: 

CD = 60 - 52^ = E7 
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